home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000026_owner-urn-ietf _Wed Mar 12 12:23:39 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  5KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id MAA02172
  3.     for urn-ietf-out; Wed, 12 Mar 1997 12:23:39 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA02167
  6.     for <urn-ietf@services.bunyip.com>; Wed, 12 Mar 1997 12:23:36 -0500 (EST)
  7. Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA22885  (mail destined for urn-ietf@services.bunyip.com); Wed, 12 Mar 97 12:23:34 -0500
  9. Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA17437; Wed, 12 Mar 1997 10:23:16 -0700 (MST)
  10. Message-Id: <3.0.32.19970312094225.00974c30@acl.lanl.gov>
  11. X-Sender: rdaniel@acl.lanl.gov
  12. X-Mailer: Windows Eudora Pro Version 3.0 (32)
  13. Date: Wed, 12 Mar 1997 10:22:25 -0700
  14. To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>, urn-ietf@bunyip.com
  15. From: "Ron Daniel Jr." <rdaniel@acl.lanl.gov>
  16. Subject: Re: [URN] URNs grandfathering certain Object or Interface
  17.   References
  18. Mime-Version: 1.0
  19. Content-Type: text/plain; charset="us-ascii"
  20. Sender: owner-urn-ietf@Bunyip.Com
  21. Precedence: bulk
  22. Reply-To: "Ron Daniel Jr." <rdaniel@acl.lanl.gov>
  23. Errors-To: owner-urn-ietf@Bunyip.Com
  24.  
  25. Hi Bob,
  26.  
  27. Nice to hear from you again. Sorry to be a little late replying, I was
  28. off-net yesterday.
  29.  
  30. >The problem is that some COM/CORBA based systems can interpret these
  31. >strings of hex digits to extract the machine/port etc. which hosts the
  32. >object they need for resolution, but the algorithm isn't a simple textual
  33. >transformation.
  34. >
  35. >How might NAPTR cope with this without just resorting to a replacement
  36. >string and lumping the whole problem on one global resolver for the whole
  37. >scheme leading to a horrible bottleneck?
  38.  
  39. Don't know anything about UUIDs, but I  know a little about IORs and CORBA,
  40. so I will answer your questions using those as examples.
  41.  
  42. Let me give four answers - three cheap ones and the real one.
  43.  
  44. Cheap answer #1 is that what you are asking for is a Turing-complete
  45. way of operating on URIs. Declare a new flag, lets say "J", and use the
  46. regexp field to carry Java bytecodes instead of regular expressions.
  47. Clients that don't know the "J" flag ignore the record, those that do
  48. know it could run the supplied bytecodes to learn how to crack such an
  49. opaque identifier and what to do with the resulting pieces. For a
  50. variety of reasons this is a bad idea, but is allowed by the draft.
  51. (Well, change "J" to a digit and it is allowed as a local experiment. Try
  52. to use an alphabetic flag and you will have to contend with people like me
  53. on the list who will oppose doing such a thing).
  54.  
  55. Cheap answer #2 is that we don't have to dump it all onto one global
  56. resolver, we can use the "S" flag and a SRV record to dump it all onto
  57. a resolver that is replicated to whatever degree one needs.
  58.  
  59. Cheap answer #3 is that instead of using one central resolver, you use
  60. some arbitrary subset of the characters in the identifier to distribute
  61. the resolutions to an arbitrary number of resolver services. For IORs we
  62. might use the last character, which will distribute the load to 16 possible
  63. places. Use the last two and we can go 256 different places, ...
  64.  
  65. There is more than one way to do what you are asking for if it really has
  66. to be done using NAPTR.
  67.  
  68. The real answer is more complex:
  69.   a) What you are asking for is more than the NAPTR system is
  70.      trying to solve. It is OK for us to start simple. There are
  71.      a lot of important namespaces, such as ISBN, SICI, .. that can
  72.      be handled using only syntactic transformations. NAPTR
  73.      is intended to be the first, not last, resolver discovery
  74.      service. Later ones can try to solve this problem directly if
  75.      experience with NAPTR shows that it is a significant problem.
  76.   b) NAPTR is intended to be a fallback resolution approach, and clients
  77.      should try other things first. IORs are references to CORBA objects,
  78.      and clients can invoke the object's methods, but only if they know IIOP
  79.      or some other way to talk to the Object Request Broker associated with
  80.      the object. Clients that speak IIOP should do so early on
  81.      and not mess with NAPTR. Clients that don't speak IIOP might end up
  82.      trying NAPTR and get back a record like:
  83.  
  84.       ior.urn.net NAPTR 1 1 "p" "iiop" "" foo.omg.org
  85.  
  86.      which tells them they need to know the IIOP protocol to do anything more
  87.      with the identifier.
  88.  
  89. Gotta go now, best regards,
  90.  
  91. Ron Daniel Jr.              voice:+1 505 665 0597
  92. Advanced Computing Lab        fax:+1 505 665 4939
  93. MS B287                     email:rdaniel@lanl.gov
  94. Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
  95. Los Alamos, NM, USA, 87545